#프론트엔드 디자인패턴

[aetywork1]

[pignose-barn]

Angular 2 그리고 웹 프론트엔드 (2/2)

이번 시간에는 Angular가 무엇인지 알아보도록 하자

연관된 글 목록

Angular 2 그리고 웹 프론트엔드 (1/2)

Angular 2 그리고 웹 프론트엔드 (2/2) - 현재 글

설명하기 앞서

이 글은 Angular의 특징을 최대한 간략하게 설명한다.

따라서 앵귤러 코드를 자세히보고 싶은 분들

Angular 코드를 보며 하악하악 하고싶어하시는 분들을 위한 글이 아니다.

간단하게 자바스크립트와 Angular 코드를 비교해보고

차이점을 설명하는 정도로 코드 첨부는 끝날 것이다.

협업에서 Angular 도입을 고려하거나,

이제 Angular가 무엇인지 알아보려는 독자를 위해 글을 작성하고 있다.

만약 여러분이 Angular에 대해 자세히 알아보고 싶다면

Angular 2 그리고 웹 프론트엔드 (3/3)을 읽어보시기 바란다.

영상에서 Angular에 대해 간단하게(30분) 설명한다.

동영상이 길기 때문에 슬라이드 자료를 보는 것을 권장한다.

프레임워크 vs 라이브러리

한때 필자가 운영하던 페이스북 페이지에서

라이브러리와 프레임워크 프로젝트를 비교하면서 프레임워크 프로젝트에서

더 많은 기능을 제공한다고 올렸던 적이 있는데.

결과적으로 가루가 되도록 털렸다. (엉엉)

프레임워크와 라이브러리가 가끔 혼용되어 사용되면서 오해가 생겼다고 생각한다.

둘의 개념은 엄연히 다른 개념이기 때문에 이 자리를 빌어 간단한게 설명을 해볼까 한다.

(사진출처: 트위터 @jaffathecake)

프레임워크(Framework): 

큰 틀(Frame)안에서 그 규칙에 맞게 정의된 기능과 라이프사이클을 지키며 기능을 개발할 수 있는 도구.

라이브러리(Library): 

기존 개발된 기능은 지키면서 라이브러리가 제공하는 기능을 추가적으로 사용하여 파워업 할 수 있는 도구.

대게 라이브러리보다 프레임워크가 제공하는 기능이 더 큰 편이며

러닝커브도 프레임워크가 더 높은 편이다.

Angular

자 그럼 주제로 돌아와서 Angular를 알아보자.

Angular는 Google에서 2009년 Feedback 서비스를 개발하는 도중 탄생된 자바스크립트 프레임워크이다.

당시만해도 화면(View)이 동���으로 바뀌는 페이지를 만들고

그곳에 이벤트 함수들을 바인딩(이벤트를 연결하는 과정)하는 로직을 추가하는 것을 짜는 과정을

고스란히 순수 자바스크립트 혹은 라이브러리로 작성했기 때문에 굉장히 코드라인이 길었다.

그 높으신 최고존엄 구글 엔지니어들도 이런 개발방식에 피곤함을 느꼈을테고

그렇게 조금 더 편리한 방법을 모색하는 도중 Angular가 만들어졌다.

본격적으로

그래서 결국 앵귤러라는 친구는 무엇일까?

과거에 필자는 앵귤러를 개발 생산성을 극대화시켜주는 프레임워크라고 설명했다.

물론 맞는 말이다. 하지만 앵귤러를 사용해오지 않았던 사람들은 이것이 도대체 어떤 방법으로 생산성을 극대화 시켜주는 것인지 와닿지 않는다.

앵귤러는 기존 방식과는 너무나도 다른 방향을 가지고 있다.

그래서 앵귤러를 실제로 사용해보지 않은 분들에게 이를 설명하는 것이 너무나 힘들다.

필자는 앞으로 앵귤러를

“자바스크립트의 문제를 다 덮어주는 프레임워크"라고 설명하고 싶다.

여러분은 이 다음 ��션에서 구체적으로 자바스크립트가 어떤 문제를 가지고 있는지 알게 될 것이다. 

다소 글이 길어질 수 있으니 우리 블로그 피그노즈 스타일대로 많은 링크와 그림을 첨부한다.

예를들어보자,

필자는 IT 개발관련 분야에서 솔루션을 개발하고 있는 개발자이다. 

C#으로 ASP.NET을 이용하여 웹 서비스를 개발하고 있으며

내가 속한 팀 외에도 회사에서는 메이저언어는 C#을 주로 이룬다.

물론 JAVA도 사용하고 있지만 결과적으로 객체 중심의 개발이 주로 이루어진다.

내 입장에서 볼 때 객체 중심 개발은 협업에 있어 상당히 적응력을 높여주고

개발에 대한 관점을 직접적으로 알려 준다.

다시 자바스크립트로 주제를 옮겨보자 

필자는 프론트엔드 개발도 같이 하고있고 자바스크립트를 사랑하고 자주 사용하고 있는 언어이다.

(필자는 이전 직장에서는 Node.js로 웹서비스를 개발하고 있었다.)

하지만 자바스크립트에는 굉장한 문제점들이 있었으니!!

첫 번째로 협업이 어렵다.

앞서 거론한 C#과 같은 타입을 제공하는 객체지향 프로그래밍은 

다른 프로그래밍 언어에서 익히 사용하는 클래스, 상속, 추상화개념을 받아들이기 때문에 협업에서 사용하는 형태가 유사하다. 

(따라서 다른사람의 코드를 쉽게 이해 할 수 있고 이로인해 협업에 용이하다.)

하지만 우리의 자바스크립트는 변수에 대한 타입을 제공하지 않는다.

마찬가지로 자바스크립트는 클래스를 사용하지 않고

프로토타입이라는 자바스크립트 고유의 객체 사용 형태를 제공하고 있다.

그리고 C#과 같이 객체 사용에 무조건 프로토타입을 제공하는 것도 아니다.

(리터럴 오브젝트를 사용한다.)

자바스크립트 디자인패턴을 보자

우리의 자바스크립트는 익명함수로 수많은 디자인패턴을 성공적(?)으로 제공한다!

���런 무수한 익명함수와 사용형태는

다른 협업에 있어 가독성을 떨어트리게 되고 심지어 코드 인텔리전트 기능으로도 확인 할 수 없어 혼란을 야기한다.

여러분이 협업 개발을 하지 않는다고 해도

여러분은 여러분이 짠 코드 가독성을 중요하게 생각한다면

자바스크립트가 얼마나 많은 가독성 문제가 있는지 알고 계실 것이다.

더 자세한 사항은 이 글을 보시길(원문)

두 번째로 코스트가 발생한다.

우리의 자바스크립트는 JSDoc과 단위테스트, JSLint와 같이 개발 도구를 이용하여

앞서 설명한 문제를 막고 프로토타입 기반으로 개발코드를 작성하면 협업문제가 개선된다.

필자도 그렇게 생각하고 있고 그렇게 개발하고 있다.

이미 이러한 문제는 오래전부터 거론되어 왔고

그것을 해결하기 위한 솔루션도 있는데 왜 이용을 안하는가?

결론은 그런 것을 알지도 못하고 그런것을 알기도 싫어하는 개발자가 존재하기 때문이다. (ㅁ..뭐?)

우리는 경건하게(?) 두손을 모아 바르게(현실적으로) 생각해볼 필요가 있다.

실무에서 개발자의 역할 중 가장 중요한 것은 서비스를 성공적으로 완성시키는 것이다.

위 사진은 “Done is better than perfect”

(단지 끝내는 것이 완벽한 것보다 낫다.)

어느 웹 서비스 회사(페이스북)에 걸려있는 문구이다.

이 글을 읽는 여러분은 너무나도 똑똑하기 때문에

업무를 하는 본질은 이미 알 것이기 때문에 설명은 생략한다.

통합 개발환경(IDE) 기본옵션에서 어느정도 빌드과정에서 런타임에서 발생할만한 문제를 잡아주는 언어(C#, JAVA, C, C++, go, rust, haskell etc)는

협업에서도 그 규칙을 지키면 되기에 안정적인 개발을 수행 할 수 있다.

다만 변수 타입제한이 없고 개발자 스타일별로 코딩방식이 아에 나눠져있는 언어들(Javascript, PHP, ruby etc)는 결국 성숙한 개발환경이 아니면 협업 불가능한 코드양산이 가능하다.

앞서 말했듯이 성숙한 개발환경을 만들기 위해서는 이미 안정적인 서비스 운영을 하고 있는 업체에서 실행이 가능하다.

따라서 그 이전에 단계에 있는 업체들은 자바스크립트로 개발하는 모든 프로젝트에서 하나의 룰을 정하고 그것을 따르게 강제해야한다.

관리자 입장에서는 다른언어와 비교할 때 그것이 불필요한 코스트가 될 수 있다.

그리고 개발 안정화를 위한 시스템 도입또한 코스트로 산정이 될 수 있다.

(이것이 자바스크립트의 단점으로 지목 될 수 있다.)

모던 프레임워크

앵귤러를 설명하기 위해서는 결국 자바스크립트의 본질적인 문제를 파악 할 필요가 있었다.

앵귤러는 프레임워크이다.

프레임워크는 모두 그 프레임워크의 규칙내에서 개발을 진행 하게 되어있다.

프레임워크답게 여러 개발 패턴들을 제공하고 있는데

버전 1에서는 service, provider, factory와 같이

일반적으로 많이 사용하는 디자인패턴을 아에 앵귤러 자체 정의형식으로 제공한다. 이곳에서 확인하세요

심지어 앵귤러 버전 2에서는 타입스크립트(Typescript)를 지원한다.

기존의 자바스크립트에서는 불가능 한 데코레이터, 클래스, 변수타입 등을 사용 할 수 있다.

위 사진은 자바스크립트로 Ajax 기능을 이용해서

원격지 JSON 파일에 맞는 UI를 반영하는 기술에 대한 도식이다.

JSON 파일을 파싱해서 for in 형태의 반복문으로

각각의 아이템에 맞는 엘리먼트 요소를 생성하여 그 엘리먼트에 맞는 이벤트를 연결해야 한다.

제이쿼리로 사용해도 메소드 사용이 조금 편리해지는 점 외에 큰 변화는 없다.

여태껏 개발자들은 이런 개발방법에 대해서 크게 불편사항을 느끼지 못했다.

하지만 이런 스타일의 개발 로직은 문제점이 존재한다.

1. 코드재활용

만약 두개 이상의 원격지에서 데이터를 받아와서 같은 UI에 반영해야 한다면 어떻게 할 것인가?

원격지에서 데이터를 받아온 이후 처리로직을 함수로 만들어 그것을 재활용 할 수 있다.

하지만 다른 자바스크립트 파일에서도 같은 처리방식을 사용하면 유틸리티 형태의 자바스크립트를 따로 모아 정리해야하고

다른 개발자가 이 유틸리티 파일을 사용하는 코드들을 모두 파악하지 않은 형태에서 수정해버리면? 사이드 이펙트가 발생하게 된다.

2. 복잡한 엘리먼트의 변형

사용자 화면에 적용된 UI에서 하나의 아이템 삭제 같은 기능을 추가하면

아이템 고유의 구분자를 이용해 삭제 처리를 하는 로직을 추가 해야한다.

삭제가 성공하면 UI에서 삭제된 엘리먼트를 찾아 지워주는 로직을 추가해야 한다.

그리고 아이템 고유의 구분자를 엘리먼트 data attribute로 제공하는 로직과 삭제 이벤트를 연결하는 로직을 엘리먼트를 추가하는 로직에 추가해야한다. (이쯤되면 해깔리기 시작한다.)

그 사이에 더보기 기능과 로딩 기능을 추가한다고 해보자.

로딩이 발생 시 아이템 리스트 하위에 로딩 이미지를 보여주는 엘리먼트를 추가하고, 로딩이 끝나면 그 엘리먼트를 삭제해야 한다.

더보기를 누르면 현재까지 가지고 있는 페이지 정보를 이용하여 다음 아이템 목록을 받아오고 엘리먼트를 추가하고 이벤트를 연결하는 로직으로 전달해야 한다.

이 과정에서 기존의 엘리먼트를 추가하고 변경하는 로직이 다른 개발자에 의해 변경되면 사이드 이펙트가 발생 할 수 있다.

3. 엘리먼트 탐색

자바스크립트와 연결된 엘리먼트를 찾으려면 엘리먼트를 직접 탐색해야 한다.

예를들어 구분자가 36번인 엘리먼트를 탐색하려면 탐색 엘리먼트 중 36을 값으로 가지고 있는 속성을 가진 엘리먼트를 찾아야한다.

엘리먼트가 가지고 있는 속성을 의존하기 때문에 속성 이름이 변경 되어서도 안되고

속성 값의 타입이 변경되어서도 안된다.

(분명 숫자 타입인줄 알았는데 문자타입으로 제공 되었으면 형변환 로직이 추가되야 한다.)

그리고 이것은 다른 개발자가 속성 이름을 변경해버리면 사이드 이펙트가 발생한다.

See the Pen BWzdOb by Kenneth Ceyer (@PIGNOSE) on CodePen.

이해를 돕기위해 소스를 첨부한다.

앵귤러는 이런 문제를 현명하게 대처한다. 

앵귤러는 사용자 화면 관점에서 개발 할 수 있는 특징을 가지고 있다.

사용자 화면과 자바스크립트(혹은 타입스크립트)는 

보이지 않는 무언가로 연결되어 있다.

우리는 이것을 바인딩 되어있다. 라고 표현한다.

이것이 핵심이다.

개발자가 코드 상으로 어떤 값을 가져오면 사용자 화면(HTML)은 값을 가져온 것을 자��으로 인지하고

그것에 맞는 엘리먼트를 자동으로 생성한다.

그리고 생성된 엘리먼트에 이벤트를 자동으로 연결한다.

변수와 사용자 화면이 1:1로 연결되어있기 때문에

개발자는 사용자 화면을 제어하기 위해서 엘리먼트를 탐색 할 필요가 없다. 

예를들어 36번 구분자를 가진 엘리먼트를 삭제하고자 한다면

배열중에 구분자가 36번인 요소를 삭제하면 사용자 화면은 이를 감지해서 삭제된 배열 요소�� 매칭된 엘리먼트를 자동적으로 삭제한다.

변수와 연관된 처리로직을 사용자화면에서 제어하기 때문에 코드재활용에 대해서 신경 쓸 필요가 사라진다. 

그리고 사용자 화면 제어와 관련한 로직은 사용자 화면에 명시 되어 있기 때문에

다른 개발자는 오직 사용자 화면을 살펴보면 된다.

이는 협업에서 코드 문서화를 하지 않아도 직관적으로 코드를 볼 수 있기 때문에 유리하다.

See the Pen mWEMNa by Kenneth Ceyer (@PIGNOSE) on CodePen.

아까전의 코드를 이번에는 앵귤러 v1.6으로 표현해봤다.

제이쿼리 코드에서 거론 되었던 문제점이 어떻게 해결되었는지 보이는가?

여러분이 앵귤러로 코드를 작성하면서 얼마나 많은 즐거움이 있을지 상상해봐라!

결론

앵귤러는 그냥 쩐다.

자바스크립트를 사용하며 무의식적으로 불편한 기능들을

앵귤러는 멋있고 똑똑하게 해결했다.

앵귤러의 장점들을 이 포스트에 모두 녹이기에는 너무 많기 때문에

추후 앵귤러 JS 강의를 통해 여러분에게 그 장점들을 소개하도록 하겠다.

앵귤러는 정말 멋있는 언어이지만 긱(Geek)을 위한 언어가 아니다.

불필요하게 우아하지도 않고, 일부러 어렵게 표현하지도 않는다.

여러분이 힙스터를 싫어하고 얼리어답터를 싫어하더라도

앵귤러는 배워서 나쁠 것이 없다.

다들 이 글을 읽었다면

앵귤러 공식문서로 들어가 앵귤러에 대해서 더 자세히 알아보기를 바란다.